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PROCUREMENT' AND DIET MANAGEMENT SYSTEM AND METHOD 

BACKGROUND OF THE INVENTION 
FIELD OF THE INVENTION 
5 The present invention relates to a system and method for diet 

management and procurement of goods or serivces over a network, 
particularly but not exclusively a public packet-switched data network such as 
the Internet. 

Various dietary sites, such as CyberDiet.com™, eDiets.com™ and 
10 phys.com are currently available on the Internet. These sites provide general 
dietary advice and have interactive content, such as calorie counters, menu 
planners and Body Mass Index calculators. 

However, existing dietary sites do not facilitate personalised weight 
loss or other dietary programmes and therefore do not encourage users to 
15 revisit the site regularly, as the information provided does not change and is 
not tailored to the individual user. 

US Patent No. 5,951,300 describes a system for providing on-line 
composite health education and entertainment in which the health profile of a 
patient is input and personalised health information is subsequently displayed 
20 to that patient. The system does not require patients to request health content 
or update their health profiles, on the assumption that many patients will not 
actively seek health information. 

US Patent No. 5,908,301 describes a system for modifying a user's 
eating behaviour, by means of a self-contained device which prompts the user 
25 when to perform actions such as drinking water and chewing. The user enters 
current and target physical parameters and the device establishes a control 
program based on these values. 

US Patent No. 5,542,420 describes a system for prescribing a suitable 
diet to users based on their personalised health characteristics. Information 
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about food consumed' and medical data is entered at terminals and 
communicated to a 'health computer', which determines the dietary 
prescription. ' 

5 AIMS OF THE INVENTION 

One of the aims of the present invention is to provide a dietary 
management system and method which provides personalised information 
and/or recommendations to users, , according to their individual preferences, 
which are recorded by the system and updated as the user makes choices 
10 based on the information or recommendations. 

An additional or alternative aim of the present invention is to provide a 
dietary management system which classifies users into appropriate groups and 
provides information to or performs services for a user at least partly on the 
basis of information relating to the group or groups to which the user may 
15 belong. 

An additional or alternative aim of the present invention is to provide 
dietary information or recommendations to users on the basis of factors other 
than their nutritional requirements, such as individual taste preferences and/or 
the local factors (e.g. price, availability) for different foods and/or religious or 
20 cultural preferences and/or time of day, day and/or season, and/or health 
factors such as allergies. 

An additional or alternative aim of the present invention is to allow 
users to combine an interactive personalised exercise programme with their 
dietary programme. 

25 An additional or alternative aim of the present invention is to facilitate 

the procurement of goods, such as foods recommended as part of the dietary 
programme, and/or services. 

An additional or alternative aim is to allow the user to visualise the 
effect of their dietary programme on their appearance. 
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SUMMARY OF THE INVENTION 

According to one aspect of the present invention, there is provided an 
electronic system in which users receive individual meal recommendations 
5 based on taste preference data. The taste preference data may be modified to 
reflect meals selected by the users. 

According to another aspect of the present invention, there is provided 
an electronic system in which there is stored information on local availability 
of ingredients and user records of the locations of different users. Food 
10 recommendation data is presented to the users on the basis of the availability 
of the constituent ingredients at the location of the respective users. 

According to another aspect of the present invention, there is provided 
an electronic system in which there is stored information on preferred times 
for different foods, and food recommendation data is presented to users on the 
15 basis of a specified time. 

According to another aspect of the present invention, there is provided 
an electronic system which stores information on the calorific values of 
different foods, receives information on the physical characteristics of 
different users and provides information on recommended foods to users on 
20 the basis of their received physical characteristics. 

According to another aspect of the present invention, there is provided 
an electronic system which stores records of users, at least some of which are 
classified into groups. In one more specific aspect, the system stores records 
of different foods, receives food selections from the food records from 
25 different users and compiles group lists relating to foods selected by multiple 
users from the same group. The group lists may be transmitted to some or all 
of the users of the respective group, or to another party. In another more 
specific aspect, the system provides dietary information to the users. If a user 
has not accessed the system for more than a predetermined length of time, the 
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system notifies other users in a specified group to which the user belongs. 
Explicit permission for this function may be required from the user. In another 
more specific aspect, the system stores information about individual or group 
preferences which are used to select options for individual users. Group 
5 preferences may be modified according to selections made by individual 
members of the group, or individual preferences may be modified according 
to selections made by other members of the same group. 

According to another aspect of the present invention, there is provided 
an electronic system which periodically receives data representing physical 
10 characteristics of users, and displays to the users a graphical representation of 
their physical appearance. 

According to another aspect of the present invention, there is provided 
an electronic system which receives data entered by users representing actual 
and target physical characteristics of users and displays to them a graphical 
1 5 representation of both their actual and target physical appearance. 

According to another aspect of the present invention, there is provided 
an electronic dietary management system which stores records of the 
individual ingredients and preferably the nutritional properties of each 
ingredient of meal recommendations, so that these can be closely matched to 
20 users' requirements, which may be defined in terms of Recommended Daily 
Allowances and/or other such standards. 

According to another aspect of the present invention, there is provided 
an electronic system for confirming, at a completion stage, transactions 
initiated electronically. A confirmation is recorded at the user's terminal on a 
25 physical medium in an electronically readable form and the user presents the 
physical medium at a point of delivery to confirm the details of the 
transaction, such as discounts specific to the transaction. Preferably, the 
details are recorded in a printed bar code. The transaction may be time- 
dependent, in which case the details are verified at the time of fulfilment, to 
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confirm that any time-dependent conditions have been satisfied. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Specific embodiments of the present invention will now be described 
5 with reference to the accompanying drawings, in which: 

Figure 1 is a diagram of the connections of a server to user terminals 
and other servers in embodiments of the present invention; 

Figure 2 shows an example of the architecture of the server of Figure 

1; 

10 Figure 3 is a flow diagram of the functions performed by a diet 

management application run on the server; 

Figure 4 is a diagram of the data inputs and outputs of the diet 
management application; 

Figure 5 is a diagram of the structure of a user record in the database 
15 of Figure 4; and 

Figure 6 is a diagram of the structure of the meals database used by the 

system. 

20 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
SYSTEM ARCHITECTURE 

As shown in Figure 1, a diet management system in an embodiment of 
the present invention is implemented by a software application running on a 
main server 2 connectable via the Internet 4 to other servers, such as an ISP 

25 server 6, an interactive TV network 8, and a wireless network 10, which allow 
access to the main server 2 by user terminals in the form of general purpose 
computers 12, wireless mobile terminals 14 and interactive TV equipment 16 
respectively. Only one of each type of user terminal is represented, but it will 
be understood that a very large number of user terminals may communicate 
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with the main server, limited only by the latter's capacity. Software 
compatible with the diet management system runs on the user terminals. The 
software may he generic internet and/or communications software, or be 
customised for the diet management system, for example by the use of 'plug- 
5 in' software. 

The main server 2 is also connected to a circuit-switched network 18, 
such as a PSTN or ISDN, allowing audio access by telephone equipment 20 
and data access by data terminals 21. Dial-in or leased line data 
communication access to the main server 2 may also be available to wireless 

10 networks 10, general-purpose computers 12 and interactive TV networks 8. 
However, the Internet is the preferred means of data communication, because 
of its near-global availability and ease of access. 

For simple input, users of telephone equipment 20 may dial directly 
into the main server and enter information on a keypad when prompted 

15 audibly to do so. Alternatively, users may dial up a call centre and exchange 
more complex information with an operator, who enters information on and 
reads information from a data terminal. Thus, the circuit switched network 1 8 
may be directly or indirectly connected to the main server 2. The user may 
also request specialised help from an adviser, who then sets up a voice call to 

20 the user, either via the Internet 4 or circuit switched network 1 8. 

An advantage of the diet management system is that various different 
types of input and information presentation terminals are available to users. 
However, the following description will refer generically to input, 
presentation and transmission, it being implicit that certain types of input or 

25 presentation may not be possible with certain types of user terminal; for 
example, telephone equipment 20 is not capable of graphical display unless 
coupled to a suitable graphical data terminal. 

The main server 2 is also connectable via the Internet 4 or circuit 
switched networks 18 to other servers 5, 7, such as hosts of affiliate websites, 
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third-party databases of dietary or other information, and supplier (merchant) 
databases to permit it to offer its selections in terms of regionality and 
seasonality. 

One example of the architecture of the main server 2 is shown in 

5 Figure 2. The main server 2 consists of one or more processors 22 connected 
to an internal bus 24 allowing read/write access to main memory 26 and a 
large non-volatile store 28, such as a hard disc array. The internal bus is 
connected, either directly or via a suitable high-speed port, to a router 30 
connected to other internet routers and implementing internet routing 

10 protocols, to a modem array 32 having multiple lines for connection to a 
PSTN, and to a data protocol adapter 34, such as an ISDN terminal adapter. 

The diagram of the main server 2 in Figure 2 is provided purely by 
way of example, as the skilled person will be aware of other suitable 
architectures. The important properties of the main server 2 is that it is 

15 connectable to a network, has the necessary capacity to serve a large number 
of users, and is able to store, update and present information from a database 
of user records and dietary information records. Preferable features include 
the ability to access the main server through alternative networks. The 
database need not be collocated with the main server 2, but may be accessed 

20 remotely via a suitable communications link. 

DIET MANAGEMENT APPLICATION 

Figure 3 is a flow diagram of the functions of a diet management 
application running on the main server 2, using suitable internet database 
25 management software, such as currently available from Oracle Corporation 
and others, which accept user input, process database records and present the 
results to the user in dynamic HTML. 

The default method of user access is through the World Wide Web, 
which is well-known to skilled persons, so that details of the necessary 
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protocols, browsers, modems and other generic aspects will not be discussed 
further. Instead, the following description will concentrate on those features 
which are specific to the diet management application. 

For ease of reference, the diet management system will be referred to 
5 hereafter as 'the system'. It is implicit in this reference that the actions 
performed by the system are carried out by the diet management application 
running on the main server 2, unless otherwise stated. 

ACCESS AND LOGIN 
10 At a first stage, users access the system either through the system 

home page (S1.0), or via various affinity web sites, for example food, exercise 

or corporate health-related sites Affl, Af£2, Aff3. 

At a login stage S2, users identify themselves to the system, for 

example by providing a user name and password. New users may register, at 
15 stage S2.0, by providing user details, and optionally account details if use of 

the system is to be charged to the user, and a new user name and password is 

established to enable the new user to log on to the system. 

Users who have been transferred from an affinity site Affl, Aff2, AfD 

may already have logged in to that site. In that case, the affinity site may 
20 transfer user details directly to the system so that the user does not have to log 

in again. 

USER DETAILS 

At a user profile display and input stage S3, the user is presented with 
25 currently stored user data, including user profile, goals and progress records, 
and is allowed to input new data and modify existing data, as explained in 
more detail below. At stage S3.0, additional information is presented to the 
user on the basis of the new or modified data. At stages S3.1, S3.2 and S3.3, a 
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similar process takes place to that at stage S3, but tailored to the users linked 
from the affinity sites Affl, Af£2 and Aff3 respectively. 

Referring to Figure 4, the database includes for each User a User 
Detail record, comprising the user details provided when the user was 
5 accepted as a new user, with any amendments subsequently made by the user. 
Referring to Figure 5, the user details include a USER record, which records 
details which do not change (apart from Post Code), as shown in Table 1 
below. Initially, storage capacity may be provided for 2 million active users, 
and hence for 2 million USER records. 



Table 1 - USER 


Label 


Description 


UserlD 


Defines user (8 Characters) 


FirstName 


First name 


LastName 


Last name 


Gender 


Gender (M/F) 


UnitPreference 


Sets metric or imperial units for display and input 


Height 


Height 


LegLength 


Leg Length 


ArmLength 


Arm Length 


FootSize 


Foot Size 


DOB 


Date of Birth 


PUK 


Immutable password in case current password is forgotten 


Active 


Whether Active (Y/N) 


PostCode 


Current Post/Zip code - repeated from USERDET record 




for faster access 


LogDT 


Log date of record 
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The USER record is marked as inactive when the user has not logged 
on to the system for 6 weeks. The system sends the user an e-mail after every 
week in which the user has not logged on, with the nature of the e-mail 
changing after every successive week that the user does not log on. 
5 User details which change slowly are stored in a current User Detail 

record USERDET, the format of which is shown below in Table 2. Assuming 
that these details change no more frequently than the record is archived (every 
6 months), approximately 10 million USERDET records will be needed. 



Table 2 - USERDET 



Label Description 

UserlD Identifies user - links to other records relating to same user 

Type Flexible record for indicating address, current post code, credit 

card numbers, PINs etc. Permitted values are defined in Type table 

TDET 

Value Value of information specified in Type field 

Active Y/N - Current record is active, historical records are inactive 

LogDT Log date of record 



REWARD POINTS 

The system allows the user to accumulate and carry out transactions 

15 with different types of reward points, such as Beenz, Airmiles and Clickmiles. 
For example, reward points may be awarded for using the system or achieving 
goals, and may be spent on additional services provided or advertised by the 
system. Reward point information is stored in a record REWARD formatted 
as shown below in Table 3. Assuming an average of 10 transactions per 

20 archive period, the number of REWARD records required will be 1 00 million. 
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Table 3 -REWARD 



Label 



Description 



UserlD 



Identifies user - links to other records relating to same user 
Type(s) of Reward Points 



TRewardID 



Transaction 



Transaction records 



Rewards 



Values of Reward Points 



Balance 



Balance of Reward Points 



LogDT 



Log date of record 



5 



10 



The TRewardID field is linked to a TREWARD table, which stores the 
names, operators, start and end dates of different reward schemes. 

MEASUREMENTS AND GOALS 

Each user is required to set Diet Goals (see Figure 4), which are 
recorded in a GOALS record as shown below in Table 4. Assuming new goals 
are set every month, between 12 and 60 million GOALS records may be 
needed. 
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Table 4 - GOALS 



Label 



Description 



UserlD 



Identifies user - links to other records relating to same user 



TargetWeight 
TargetWaist 
TargetHips 
TargetDate 



Date by which target is to be achieved 

Reason for dieting - choice from a list in record TCAUSE 



Target weight 
Target waist 
Target Hips 



TCauselD 



TActivitylD Type of Activity Level - Linked to Table of possible 



The system allows users to set various parameters, such as target 
weight, target waist, and the date by which the target is to be achieved. 
5 However the system rejects unrealistic goals, such as losing more than 2 lb. 
(0.9 Kg), or 1,2% of body weight per week. Alternatively, the user may be 
prevented from submitting such unrealistic goals to the system by software, 
such as an 'applet', running on the user terminal, or by an operator at the call 
centre. To enable the system to compare the user's performance against the 
10 goals, and to provide suitable health-related advice, the user is prompted to 
enter variable measurements as described below. 

The current and historical physical dimensions of the user are stored in 
a RECORD record shown below in Table 5. Assuming new dimension 
records are entered every month, between 12 and 60 million RECORD 
15 records will be needed. 



values -TACTIVITY 



Active 



Whether record is current or historical 



LogDT 



Log date of record 
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Table 5 - RECORD 



Label Description 

UserlD Identifies user - links to other records relating to same user 

LogDT Log date of record 

ProfileSet Identifies the Profile Set against which one aspect of the 

user profile can be measured. Each profile set measures a 
different aspect - food, exercise, etc. 

Value 1 The Value of Value 1 for this Profile set 

Value2 Ditto for Value 2 

ValueS Ditto for Value 3 

Value4 Ditto for Value 4 

Value5 Ditto for Value 5 

Active Whether this record is active. There can only be one active 

record for User and each Profile set 



Profile Sets are used to store sets of information about each user. One 
such set is a physical information set containing Weight, Waist and Hips 
5 measurement fields; another is a preference set containing food taste 
preference fields, exercise preference fields, and other fields. Each Profile Set 
is described in detail in a PROFILE record as shown below in Table 6: 
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Table 6 - PROFILE 



Label 



Description 



ProfileSet 
ProfileName 
ProfileDescr 
Value IName 
Value IDescr 
Value 1 Max 
Value IMin 
Value IDefault 
Value lUsrlncr 

Value lGrpIncr 



Etc.... 

Value5GrpIncr 
LogBy 



The ID of the Profile Set 

The name of the Profile Set 

The description of the Profile Set 

The Name of Value 1 (Each Profile Set has 5 Values) 

The description of Value 1 

The maximum value for Value 1 

The minimum value for Value 1 

The default value for Value 1 

The amount by which Value 1 is incremented when user 
entered 

The amount by which Value 1 is incremented when Group 
entered 

The same set of records is repeated for each of Values 2 
through 5 



The person who has entered the information in this record 



The system calculates useful indicators of the user's health, fitness and 
5 dieting needs from the USER, RECORD and PROFILE records, and displays 
these to the user. For example, the system calculates the Body Mass Index 
(BMI - mass in kg divided by the square of the height in metres) and indicates 
the implications of the calculated value of BMI graphically. If the BMI lies 
between 19 and 22, the colour green is displayed to indicate that the value is 
10 ideal; if between 22.1 and 24.9, the colour orange is displayed to indicate risk; 
above 25, the colour red is displayed to indicate danger. If the BMI is 30 or 
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above, or below 19, the system will withhold dietary information from the 
user and display a message advising the user to consult their doctor. 

At stage S4 shown in Figure 3, the user may select different support 
options in order to obtain information, advice or encouragement about their 
5 diet and exercise goals and progress, either in the form of an electronic 
display, or by requesting a call from a human adviser who has access to that 
user's records. The supply of external support information is represented by 
step 4.0 in Figure 3. 

10 EXERCISE 

The user is required to enter a general level of exercise, which is 
recorded in GOALS as shown above in Table 4. As an option, the user may 
enter a specific type of exercise performed on a particular day. The system 
may suggest suitable exercises compatible with the user's general level of 

15 exercise, or suggest a higher level of exercise to assist with the user's diet. 
The selected type of exercise is recorded to allow the daily calorie allowance 
of the user to be adjusted accordingly. 

As shown in Figures 3 and 4, the user may enter Activity Goals, such 
as a minimum level of exercise to be performed each week, at stage S3, S3.1, 

20 S3. 2 or S3. 3. The user may also enter or amend details of actual exercise 
performed each day and the system indicates whether the user has met the 
Activity Goals, and if not how much more exercise is needed to achieve these. 
The system performs checks to ensure that the Activity Goals are not 
unrealistic on the basis of the user's exercise history and other details of the 

25 user profile. 

At step S6 (S6.2 for users from the affinity site Aff2) an Exercise 
Engine, as shown in Figure 4, derives a list of Activity Choices to be 
performed on a particular day. The Activity Choices are presented to the user 
(step S6.0) and the user selects one of these options. More advanced users can 
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simply select the number of Calories to be expended in exercise that day. If 
the user actually performs a different activity, or none at all on that particular 
day, this selection can be subsequently amended at stage S3, S3.1, S3. 2 or 
S3 .3. 

5 The user's exercise details are stored in records including the UserlD, 

an Activity type code linked to an Activity type table and indicating the type 
of activity, the duration of the activity, and the Calories burned, as calculated 
by the Exercise Engine according- to the user's current weight, activity type 
and duration. 

10 The Activity Choices are selected so as to match the user's activity 

goals. The Exercise Engine also takes into account the user's previous 
selections of Activity Choice in compiling the current list of Activity Choices. 
For example, if the user has never or seldom selected a certain type of 
exercise, this type of exercise is no longer included in the Activity Choices. 

15 

AVATARS 

Advantageously, at stage S4, the system displays to the user a 
representation of their current and/or target bodily shape, to encourage the 
user to achieve their dietary goals. This type of virtual representation of a user 

20 is often referred to as an avatar, but is most commonly used by internet-based 
software, such as Virtual Places chat software, to represent a user to other 
users. The avatar of the present system may also be used in this way by other 
applications within the system, such as in a virtual chat room in which users 
may discuss diets and fitness. 

25 The weight and dimensions from the USER, GOALS, RECORD and 

PROFILE records are submitted to a graphics routine which generates a 
representation of a human body to scale having the specified weight and 
dimensions. The avatar may be further customised to resemble the user more 
closely, by allowing the user to input additional physical dimensions and 
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characteristics. Advantageously, the user uploads to the system via a high- 
speed data connection a digital photograph of their face or whole body which 
is mapped by the system as a 'skin' or surface pattern onto the representation 
of the human body, and displayed to the user. Alternatively, to reduce the 
bandwidth requirements between the system and the user terminal, the system 
may transmit the necessary parameters to graphical software running on the 
user terminal, and the digital photograph is stored and manipulated locally at 
the user terminal. 

Optionally, the user may modify the avatar by selecting specific 
clothing, hairstyle and/or makeup, selected from a range of options presented 
by the system. This feature allows the user to create an ideal look for the 
target avatar, for example, or simply to make either the current or target avatar 
look more like the user. The system creates a USER DRESS record of the 
options selected, of the form shown below in Table 7: 

Table 7 - USER DRESS 
Label Description 

UserlD Identifies user - links to other records relating to same user 

TasteType Selects a category from a Taste Type table, such as Fabric, 



The USER DRESS records are processed to generate reports of the 
tastes of the users. Additionally, the system may recommend to the user 
specific items of clothing or beauty products from affiliate web sites, based on 
the selected options. 



TasteVal 



hairstyle, makeup, lipstick 

Selected option for the category indicated by TasteType, 
such as floral, Bouffant, dark red 



LogDT 



Date record logged 
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GROUPS 

Thus far, all of the information used as input by the system relates to 
an individual user. However, the participation of peer groups or families plays 
a large part in successful dieting. The system allows the user to join one or 
5 more groups of other users and takes into account properties of that group, as 
explained below. 

The system stores GROUPUSER records each of which records the 
membership of one group by one user, as shown below in Table 8: 



Table 8 - 


GROUPUSER record 


Label 


Description 


GroupID 


Identifies group 


UserlD 


Identifies user member of group 


StartDT 


Start date of membership 


EndDT 


End date of membership 


Active 


Whether record is current or historical 



As shown in Figure 5, the existence of each group is recorded in a 
GROUP record, as shown below in Table 9: 
Table 9 - GROUP record 
Label Description 
GroupID Identifies group 

GroupName Name of group 
Active Whether record is current or historical 

LogDT Logging date of record 

Membership of a group is either selected by a user or inferred by the 
system. For example, users referred by an affinity site are automatically 
entered into a group specific to that site. As another example, the system 
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detects multiple users resident within the same local area, and asks those users 
to confirm whether they wish to be added to a neighbourhood group. For 
neighbourhood or affinity groups, each user is asked whether they have 
preferences (e.g. gender specific) for the type of other members of the group. 
5 Users who wish to form a group, for example having discussed their 

diets using the chat room facility, may set up user-defined groups by having 
one prospective member select a name and password for the new group, and 
allowing other users to join the group if the correct password is supplied. 

A family group is automatically created for each new user, unless the 
10 user indicates that they wish to join the family group of an existing user, in 
which case the user name and password of the existing member are entered 
and, if recognised by the system, the new user is added to the family group of 
the existing user. 

The family group is used by the expert engine to co-ordinate the meals 
15 and shopping lists of each member. Thus, when selecting meals for suggestion 
to a user, the system looks up the menu selections, if any, of the other 
members of the family group and, if those menu selections are compatible 
with the nutritional requirements and diet goals of that user, includes those 
menu selections in the options displayed to that user, indicating which other 
20 family member has chosen that option. 

The system also creates group shopping lists and restaurant orders for 
family groups. Thus, instead of creating an individual shopping list or 
restaurant order as described above, the system adds the ingredients or meal 
orders for the current user to the family group shopping list or restaurant 
25 order. The system indicates to the user whether all of the family group 
members have made a menu selection for a specific day or meal and allows 
the user to complete the shopping list or order. The completed shopping list is 
displayed or sent to the user, for example as an e-mail, and a new group 
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shopping list is created. Likewise, a completed order is sent to the relevant 
restaurant or restaurants and a new group order is created. 

Groups are also used by the system to encourage members of a group 
to support other members who are failing to use the system. For example, if a 
5 user has not logged onto the system for a certain period of time, such as three 
weeks, the system sends an e-mail to other members of the group encouraging 
them to support that user. For privacy reasons, this feature is only enabled if 
selected by the user. 

. . GROUPUSER and GROUP records are also used by the system to 

10 store further information about groups of users. For example, language group 
records are used to record the preferred language of users. The system looks 
up the language group of the user and uses this information to determine the 
language in which text is displayed to the user and the language used to 
deliver information over the telephone. Language groups are also used by the 

15 system, preferably in conjunction with address information, to select meal 
options. For example, a Chinese speaker living in London may have food 
tastes which are more typically Chinese than Western. Currency groups are 
used by the system to identify the currency in which a user should be charged 
for goods or services. 

20 

PROFILES 

One particularly advantageous feature of the system is its ability to 
record the user's changing preference profiles and provide information or 
recommendations to the user based on those profiles. 
25 One function of the user profiles is to recommend menus customised 

to the individual nutritional needs and dieting goals of each user, and to a food 
preference profile for each user. Before a user has made any menu choices, the 
system sets an initial food preference record for that user, based on a group 
food preference record for the cluster group to which the user belongs. The 
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cluster group is determined by the user's entry point into the system (there 
may be several URL's for different 'flavours' of the site) or by interrogation 
of the user. 

The user's taste profile is recorded as a three-digit code from 000 to 
5 999, with each digit representing one quality to be matched to possible meal 
options (e.g. intensity/blandness, complexity of preparation, sophistication), 
but more digits may be used to record other qualities. 

The system creates PROFILE records of the user's food preferences 
and nutritional requirements, as shown above in Table 5. The system also 
10 maintains a current requirement for the user in terms of the recommended 
daily allowances for the various components if ingredients as shown below in 
Table 10. 



Table 10 - USERREQ 



Label 



Description 



UserlD Identifies user - links to other records relating to same user 

CalReq Daily calorie requirement 

CarbReq Daily carbohydrate requirement 

ProtReq Daily protein requirement 

FatReq Daily fat requirement 



Active 
Log DT 



Whether record is current or historical 
Date of logging record 



INGREDIENTS 

The system includes a database of nutritional information on 
ingredients and meals composed of those ingredients, represented by Figure 6. 
About 5,000 records of different basic ingredients are stored. INGREDIENTS 
records are of the form shown below in Table 1 1 : 
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Table 11 - INGREDIENTS 



Description 



IngredID 
FoodGroup ID 



PortionID 

Water 

CalCon 

Protein 

Carbohydrate 

Glycemic index 

Dietary Fibre 

Calcium 

(other nutrients) 

Fat 

Fat: Saturated 

FatMonounsaturated 

FatPolyunsaturated 

Cholesterol 

HCA 

LogBy 

LogDT 



Identifies ingredient 

Identifies food group of ingredient (beans, beverages, 

dairy products, milk & cream, fats & oils, fruit and 

fruit juice, grain products, pasta, condiments, meat, 

nuts, seeds and related products, seafood, vegetables 

and vegetable juices, candies) 

Standard portion size for this ingredient 

Water content per standard portion (g) 

Calorie content per portion (kcal) 

Protein content per portion (g) 

Carbohydrate content per portion (g) 

Glycemic index 

Dietary Fibre per portion (g) 

Calcium per portion (mg) 

(individual records for other nutrients) 

Total fat (g) 

Saturated Fat (g) 

Monounsaturated Fat (g) 

Polyunsaturated fat (g) 

Cholesterol (mg) 

Hydroxycitric acid (mg) 

Source of Information 

Logging date of record 



The contents of the INGREDIENTS records may be based on the 
5 USDA Ingredients database, but further fields may be added to accommodate 
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the ingredient breakdown formats of other authorities relevant to the countries 
in which the system operates. 

The system also stores a database of products (Prodlngred in Figure 6) 
which comprise the ingredients required for the menu options. Information on 
5 these products, such as pack size and nutritional content, are obtained from 
the manufacturer. 



MEALS 

The system also stores MEALS records which store the composition 
of different meals in terms of the quantity of different ingredients stored in 
INGREDIENTS records, in the form shown below in Table 12: 
Table 12 - MEALS 
Label Description 
MeallD Identifies meal 

IngredientID Lists the identities of the ingredients which make up the meal 
Quantity Lists the quantity of each ingredient 
LogBy Source of Information 

LogDT Logging date of record 



An additional field may be included, identifying any preferred time of 
15 day for the meal or type of meal (morning, midday, evening, snack or drink). 

For each meal, the system stores a set of 1000 MEALMATCH records 
of the degree of matching between that meal and each user taste profile, from 
000 to 999, as shown in Table 13: 
Table 13 - MEALMATCH 
Label Description 
MeallD Identifies meal 

PersTasteA First digit of user taste profile 
PersTasteB Second digit of user taste profile 
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PersTasteC Third digit of user taste profile 

Match Degree of matching between meal and the user taste profile 

(%) 

The MEALMATCH records simplify the task of matching meals to 
the individual user's tastes, as will now be described. 

5 MEAL RECOMMENDATION . 

The system determines a customized menu for the user, represented as 
stage S5 (or S5.3 for users from affinity site Aff3). An expert engine EE, 
forming part of the system, and represented in Figure 6, looks up from the 
stored records the nutritional requirements of the individual user, the user's 

10 food preference tastes, the user's dietary goals, and the user's current level of 
exercise and calculates personalised taste and nutritional requirements. The 
expert engine then selects, from the MEALS records, individual meals or 
combinations of meals for the next 24 hours or a longer predefined period 
which closely match the taste and nutritional requirements of the user. The 

15 selection for taste match is taken by selecting the MEALMATCH records 
containing a profile closest to the user's current profile and then extracting the 
MEALS records corresponding to the selected MEALMATCH records. 

Preferably, at least three options are presented for each meal, and are 
displayed to the user for selection (step S5.0). The user then selects one of the 

20 options for each meal, or chooses another meal which was not selected by the 
expert engine, for example by a keyword search of the MEALS records or the 
component ingredients of each meal. For example, if the user does not have 
the ingredients required for any of the suggested meal options and does not 
wish to shop for those ingredients or order the complete meal, the user may 

25 search using the names of those ingredients which are available. 
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The expert engine calculates the total permitted calorific content for 
meals in the selected day, on the following basis. First, the basic number of 
Calories (kcal) needed to maintain the user's current weight is calculated by 
multiplying the user's current weight in kg by 30. For example, an 80 kg 

5 person is assumed to require 2400 kcal/day. Next, an exercise allowance is 
added according to the user's activity level, or for specific exercises selected 
by the user for the previous day. The system stores a table of calorific 
equivalents of specific exercises and of general activity levels and looks up 
the additional allowance from this table. 

10 The total of the basic and exercise allowance is reduced by a weight 

loss amount according to the weekly weight loss set by the user's goals. To 
lose 0.5 kg per week, 500 kcal/day must be subtracted from the daily 
allowance. Hence, the weight loss amount is calculated by subtracting the 
value of TargefWeight from the value of Weight, dividing the result by the 

15 number of days between TargetDate and the current date, and multiplying by 
7000. If the user wishes to gain weight, then the Calorie reduction will be 
calculated as negative and the daily Calorie allowance increases. 

Next, the expert engine EE divides the total daily allowance into 
calorie ranges for each meal type, for example as shown below in Table 14: 

20 

Table 14 -Consumption Profile 



Meal Type 


Average 


Min 


Max 


Morning 


20% 


15% 


35% 


Midday 


30% 


15% 


35% 


Evening 


25% 


15% 


35% 


Snacks 


10% 


0% 


15% 


Drinks 


15% 


0% 


20% 



For each meal type, the expert engine selects meal options which fall 
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within the permitted Calorie ranges. As the user makes a choice for each meal 
type, the meal options for the meal types not yet selected are adjusted to stay 
within the proportions identified for the respective meal type. When the last 
choice is made for a particular day, the total calorific value may be greater or 

5 less than the daily allowance. If the shortfall or excess is greater than a 
threshold percentage, such as 5% or 10%, the user is warned of this and asked 
to confirm the selection for that day. 

Advantageously, the system takes into account further user-defined or 
user-dependent criteria when selecting and presenting meal options to the 

10 user. In one option, the user selects a particular type of diet regime, such as 
vegetarian, Atkins diet or cabbage diet. The system stores a set of rules for all 
commonly encountered diet regimes and the expert engine applies these rules 
to the MEALS records to select only those meals which comply with the diet 
regime. For example, the rules may exclude specific ingredients or food 

15 groups, or combinations of specific ingredients or food groups within the 
same meal. 

In another option, which is selectable by the user, the expert engine 
takes into account the country or area of residence of the user, as stored in the 
USERDET record, and/or the current day, month or season. The 

20 INGREDIENTS record may include a field listing the countries or areas in 
which the ingredient is available, and/or the date range for each country 
within which the ingredient is available. The expert engine then selects for 
presentation to the user only those meals which use ingredients available in 
the user's area on the day or within the period for which the user requests 

25 meal recommendations. 

In another option, the system detects whether the day for which the 
meal suggestions are requested is a special day for that user. A special day 
may be the user's birthday, which is detected from the USER record, a 
national holiday in the user's country of residence (e.g. Thanksgiving in the 
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US) or a religious festival appropriate to the user (e.g. Christmas), if the 
USERDET or USER records include a field indicating the religion of the user. 
The system stores a table of special days for each user, together with a meal 
option selection rule appropriate for each special day (e.g. select one meal 
with turkey, ham or goose as an ingredient for Christmas or Thanksgiving; 
allow a certain percentage increase in calories for a birthday). 

The system stores MENU records which record what menu was 
allocated by the system for each meal for a given user, and what the user 
actually selected to eat. Six different 'meals' can be recorded per day, 
comprising morning, midday and evening meals, snacks, drinks and 
supplements. Assuming that all six meals are recorded per day by each of 2 
million users, and allowing for a six month archive period, 12 billion MENU 
records are needed. The MENU records have the format shown below in 
Table 15: 

Table 15 - MENU 

Label Description 

UserlD Identifies user - links to other records relating to same user 

Date Date 

MealTimelD Identifies type of meal (morning, midday, evening, snacks, 

drinks, supplements) 
MeallDl, Identify the first, second and third meals suggested by the 

MealID2, system 
MealID3 

MeallDChoice Identifies which meal (suggested or otherwise) the user 
chose 

LogDT Date of logging record 
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Every time a new MENU record is created, the system adjusts the 
user's PROFILE record to reflect any trend in the user's tastes. For example, 
Table 16 below shows how the PROFILE record changes after a meal 
selection. For each Profile Set (as described in Table 5), a taste adjustment 
5 rate (Usrlncr) is defined which determines the degree of change of each value 
each time a meal taste profile higher or lower than the current user taste 
profile is selected; in this case the taste adjustment rate is 0.2 for each 
criterion A, B, and C: 

10 Table 16 - PROFILE adjustment 



Description 


A 


B 


C 


User Taste Profile before meal selection 


3.0 


7.0 


6.0 


Taste profile of meal selection 1 


7.0 


7.0 


6.0 


User Taste Profile after meal selection 1 


3.2 


7.0 


5.8 


Taste Profile of meal selection 2 


7.0 


7.0 


6.0 


User Taste Profile after meal selection 2 


3.4 


7.0 


5.6 


Taste Profile of meal selection 3 


4.0 


7.0 


5.0 


User Taste Profile after meal selection 3 


3.4 


7.0 


5.4 



Each PROFILE record may also be adjusted according to selections 
made by other members of any of the groups to which the user belongs. As 
shown in Table 6 above, a Group Increment rate (GRPIncr) is defined for each 
15 value in the Profile record, and the appropriate value is increased or decreased 
by the group rate each time another member of the same group makes a 
selection with a value grater than or less than tire current PROFILE value for 
the user. 

As an additional or alternative feature, a group PROFILE may be 
20 defined for each group, and the group profile values are increased or 
decreased in response to individual selections by members of the group. 
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The user may amend historical MENU records to reflect any 
differences between what the user selected on the system and what the user 
actually ate. 

5 PROCUREMENT 

Once the user has selected a menu for a specified date, or for each of a 
range of dates, the system then facilitates the acquisition of the selected meals 
or the necessary ingredients for those meals, as represented by stage S8 in 
Figure 3 (or S8.3 for users from affinity site Aff3). If the user wishes to pay 

10 for the selected meals or ingredients through the system, and is not registered, 
account information is obtained from the user (step S7.0). Order information 
(S8.0) and payment information (S7.1) may be transmitted to the appropriate 
suppliers. 

The user selects how each meal is to be procured. The procurement 
15 categories include home cook, pre-made (buy from shop but heat at home), 
take-out (fully prepared by restaurant or other outlet, and collected or 
delivered) or restaurant. 

If one or more home cook or pre-made meals are selected, the system 
compiles a 'shopping list' of the ingredients required for those meals, and 
20 displays these to the user. These ingredients may be displayed as generic 
ingredients, or as specific products derived from the Prodlngred database. 

Where some of the menu choices are meals only available from a 
specific supplier which allows on-line ordering, the user may choose to be 
transferred to the site of the appropriate supplier, ' and information on the 
25 required meals and any ingredients available from that supplier is also passed 
to the host of that site. The user then removes any items which the user 
already has, or adds any other items required to the order, before submitting 
the order. The order may then be collected by or delivered to the user. 
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The MEALS records may include links or pointers to files which 
provide the user with additional information about that meal, such as a recipe, 
or a video clip demonstrating preparation of the meal. The use of video 
demonstrations is particularly suitable for interactive television terminals 16. 
5 The system presents the user with the option to view the additional 
information. 

The MEALS records preferably include records of specific meals 
available from restaurant chains, including a field identifying the restaurant 
chain or chains serving that meal. If one of those meals is selected for a future 

10 meal time, the system displays to the user the identity of the restaurant chain 
or chains serving that meal. As a further option, the system stores a directory 
of addresses of restaurants serving meals stored as MEALS records, and 
selects the closest branch of a chain by comparing the postal or zip codes of 
the branches with the current post code of the user in USERDET. The closest 

15 branch is displayed to the user, and, if requested by the user, an order is sent 
to the closest branch, for example by fax or e-mail, or by adding the order to a 
order file to which orders from other users are added before sending the order 
file off to the branch or chain headquarters. 

If a specific exercise has been selected, the user is presented with the 

20 option to procure goods or services to facilitate that exercise (step S9 or step 
S9.2 customised for users from affinity site Aff2), for example gym 
membership or exercise equipment. If this option is selected, the user may be 
transferred to a site offering such goods or service, together with information 
indicating the user's selection (step S 9.0). 

25 Another advantageous feature of the system is its ability to exchange 

information With merchant servers (such as the servers 5 and 7) operated by 
suppliers of food and other products, to assist the user in purchasing food or 
other products recommended by the system. In one example, the merchant 
servers provide information on the current pricing of items available from 
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respective supermarket chains, which information may be updated daily, for 
example. The pricing information includes regional availability information, 
such as an indication of which products are available only from some stores. 
The current pricing information is stored on the server 2, so that when a user 

5 has compiled a 'shopping list', the system calculates the total price of the 
items on the shopping list from each of the supermarket chains from which 
pricing information has been obtained. The system compares the user's home 
location with any regional availability information in the pricing information, 
and takes this into account by using the pricing information relevant to the 

10 branch of the supermarket chain closest to the user. The system also indicates 
whether any of the ingredients is unavailable from each supermarket chain or 
from the some or all branches of each supermarket chain within a specified 
distance from the user. 

The system also allows transaction-specific pricing for the list of 

15 goods according to a number of factors, as will be described below. The 
pricing information stored by the server comprises a pricing record for each 
merchant, and optionally for each outlet, of the different ordering options 
available and their effect on the total price. The pricing record defines 
delivery options, such as home delivery or collection by customer. Home 

20 delivery is more expensive to the merchant and removes the possibility of 
impulse buying, and the home delivery option may therefore carry a fixed 
charge or a percentage uplift on the total price, which is recorded in the 
pricing record. The pricing records also defines picking options, such as store 
picking (order assembled by staff) or customer picking (order assembled by 

25 customer). The former is more expensive to the store in terms of labour costs 
and the removal of impulse buying, and therefore has an additional charge 
recorded against it. The pricing record also includes a repeat order field, 
which defines options for repeating the order at different intervals, such as 
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weekly or monthly, and records discounts which are offered to the user for 
making repeat orders. 

The pricing record also includes a time option field, which defines 
. different times at which the customer may visit the store, and associated price 
5 adjustments. The time option field may define adjustments associated with 
each of a time of day, a day of the week or a week of the year. This field 
allows the merchant to offer incentives to users to visit the store at quiet 
times. 

The pricing record also defines product-related pricing adjustments for 
10 selecting products in a specific pack size or for selecting equivalent products. 
For example, the pricing record may define pack options, such as larger packs 
which may have a cheaper price per item, volume or weight, or product 
options, which record whether a cheaper equivalent brand is available. 

The pricing record also defines discounts available for spending over 
15 different thresholds, with pricing adjustments recording the percentage 
discounts available at each threshold. User Groups are also identified to which 
additional discounts are available, such as cluster groups targeted by the 
specific merchant. The pricing record may also define discounts available for 
exceeding specified numbers of orders from that merchant. Finally, the 
20 pricing record defines parameters of a random discount which is offered by 
the system on a per-user basis within limits defined by the merchant or the 
store. 

The different options defined in the pricing record for a selected 
merchant or store are presented to the user, and the system recalculates and 
25 indicates the total price to the user as the options are selected. Once all 
necessary options have been selected, the user then confirms the order through 
the system, which causes a list to be printed out or otherwise recorded at the 
user's terminal, and/or recorded on the supplier database against a customer 
ID or Loyalty Number or as a generated Deal Number or in any other form 
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verifiable against a customer claim, so as to record the items and options 
selected, together with the pricing offered by the merchant. 

As an alternative, once the necessary options have been selected, the 
user may make an offer instead of accepting the price calculated by the 

5 system. In that case, the system forwards the list of items and options selected 
by the user to the merchant server which processes orders from an outlet 
selected by the user. The merchant server sorts all received offers according to 
. benefit to the merchant, such as by profit, and periodically selects the most 
beneficial for acceptance. For the selected offers, a list of details of the 

10 acceptance is sent to the respective user. Otherwise, an e-mail notification is 
sent to an unsuccessful user, including a URL which takes the recipient back 
to the ordering stage, with the list of items filled in but some or all of the 
ordering options not completed. The unsuccessful users may then change the 
ordering options and/or the offer price and resubmit an offer. 

15 When an offer is made to the user by a merchant, or an offer by the 

user is accepted, a list of details is presented to the user in a form which can 
be recorded on a physical medium at the user's terminal and/or recorded on 
the supplier database against a customer ID or Loyalty Number or as a 
generated Deal Number or in any other form verifiable against a customer 

20 claim, and carried with the user to the branch of the supermarket, if the user 
has selected customer collection. The physical medium and/or supplier 
database provides a record on the on-line order so that the appropriate price 
can be claimed by the user. 

Preferably, the system sends a series of bar-code images to the user, 

25 who then prints the bar-codes and takes the print-out to the selected 
supermarket. The bar codes identify the customer, who must be pre-registered 
with the merchant, the order, including a time-stamp, and the products 
ordered. The information is scanned at the branch and checked against records 
on the supermarket chain's computer system to verify that the offer has been 
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made, that the customer details are correct and that the list of items has been 
or is being bought. Each order has a specified duration of validity, and the 
time-stamp is checked against the current time to ensure that the order is still 
valid. Additionally, where the order included a time-dependent option, the 

5 indicated collection time is checked against the actual time of fulfilment of the 
order to ensure that the user has collected the items at the time or date selected 
- if not, a price penalty may be added. If the bar-coded details are verified, the 
price charged to the customer is then based on that specified in the order. 

The use of a bar code does not require the user to acquire any 

10 additional hardware or software and can easily be scanned at outlets which 
already use bar-code scanners for identifying products. However, as an 
alternative where the user has a smart card writer/reader connected to the 
user's terminal, the special offer information may be stored on the user's 
smart card, which is then read at the branch. 

15 The scanned information may include a code which indicates that the 

offer was negotiated through the diet management system, which enables 
commission payments to be made from the suppliers to the operator of the 
diet management system when the purchase from the supplier is complete. 

As another alternative, all of the details of an on-line order are stored 

20 on the supplier database and the customer need only provide some means of 
identification, such as a loyalty card bearing the customer's signature, in order 
to be linked to the appropriate order record on the supplier database. 

Many of the described features may be implemented only if selected 
by the user, or selectively made available by the system. For example, the 

25 system may allow a 'guest login' in which a user does not provide a full set of 
information and is allowed to access only certain functions of the system. The 
system may discard guest login records once the guest user has left the site. 
Account details may be required from users before they can become registered 
users of the system, and a charge made per visit to the site, or for specific 
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types of information. Alternatively or additionally, a commission system may 
operate in which businesses to which users are referred by the system, such as 
restaurants or beauty product vendors, pay the operator of the system a 
commission on purchases made by the user. 

5 Many of the features described above can be provided independently 

of the other features. For example, the procurement options could be provided 
as part of an on-line ordering service independently of any dietary 
recommendations. 

It will be apparent to the skilled reader that the above system may be 

10 modified in many ways without departing from the scope of the present 
invention, as defined by the claims. 
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CLAIMS 

1. A method of selectively providing dietary data to any of a plurality of 
users, including: 

5 electronically storing a database of a plurality of food records each 

including food identity data identifying a specific food and taste factor data 
identifying a taste factor for that food; 

electronically storing one or more taste preference records relating to 
each of said multiple users, each taste preference record indicating a taste 
10 preference relating to a specific user; 

for at least one of said users, selecting a set of one or more food 
records on the basis of a comparison between the or each taste preference 
record for the respective user with the taste factor data of some or all of said 
food records, and 

15 transmitting, to the respective user, food recommendation data derived 

from the food identity data of the selected set. 

2. A method as claimed in claim 1, wherein the set comprises a plurality 
of said food records, the method further including: 

20 receiving from the user a food selection indication signal identifying 

one or more of said specific foods, and 

modifying one or more of the taste preference records relating to that 
user in response to the food selection indication signal. 

25 3. A method as claimed in claim 2, wherein the food selection indication 
signal indicates a subset of the selected set of food records. 

4. A method of selectively providing dietary data to any of a plurality of 
users, including: 
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electronically storing a database of a plurality of food records each 
identifying a food, and local availability information for that food, indicating 
where that food is available; 

electronically storing a location record relating to each of said multiple 
5 users, each location record indicating the location of a specific user; 

for at least one of said users, selecting a subset of said set of food 
records on the basis of a comparison between the location record for the user 
and the local availability information of some or all of said foods, and 

transmitting to the respective user food recommendation data derived 
1 0 from the food identity data of the selected set of food records. 

5. A method as claimed in claim 4, further including storing a list of 
ingredients and local availability information for those ingredients, wherein 
the food records indicate the ingredients of the corresponding foods and the 

15 local availability information for said foods is derived from the indicated 
availability information of the ingredients of the foods. 

6. A method as claimed in claim 4 or claim 5, wherein the local 
availability information further indicates time of availability and the selecting 

20 step is performed further on the basis of a comparison between variable time 
data and the local availability information, according to whether the foods are 
available at the location of the user at the time indicated by the variable time 
data. 

25 7. A method of selectively providing dietary data to any of a plurality of 
users, including: 

electronically storing a database of a plurality of food records each 
including food identity data identifying a specific food and time-dependent 
data indicating a preferred time for that food; and 
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for at least one of said users, selecting a subset of said set of food 
records on the basis of the time-dependent data of some or all of said food 
records, and 

transmitting to the respective user food recommendation data derived 
5 from the food identity data of the selected set of food records. 

8. A method as claimed in claim 7, wherein said time-dependent data 
relates to a preferred time of day for that food, and the subset is selected on 
the basis of a specified time of day. 

10 

9. A method as claimed in claim 7 or claim 8, wherein the time- 
dependent data relates to a preferred day for that food, and the subset is 
selected on the basis of a specified day. 

15 10. A method of selectively providing dietary data to any of a plurality of 
users, including: 

electronically storing a database of a plurality of food records each 
identifying a specific food and a calorific value of that food; 

electronically storing physical characteristics records relating to each 
20 of said multiple users; 

for at least one of said users, calculating a calorific requirement of the 
respective user from the one or more physical characteristics records relating 
to the respective user, 

selecting a set of said food records according to said calculated 
25 calorific requirement, and 

transmitting, to the respective user, food recommendation data derived 
from the selected set of food records. 
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11. A method as claimed in claim 10, wherein the physical characteristics 
records include actual and target physical characteristics records, the calorific 
requirement for the respective user being calculated according to a difference 
between the values of the actual and target physical characteristics records. 

5 

12. A method as claimed in claim 11, wherein the physical characteristics 
records further indicate a target interval for achievement of the target physical 
characteristics indicated by the target physical characteristics records, the 
calorific requirement being calculated additionally according to said target 

10 interval. 

13. A method as claimed in any one of claims 10 to 12, further comprising 
storing exercise records representing exercise performed or to be performed 
by the respective users, wherein the calorific requirement is calculated 

15 additionally according to said target interval. 

14. A method of selectively providing dietary data to any of a plurality of 
users, including: 

storing electronic records representing groups of said users, at least 
20 some of said groups comprising more than one of said users; 

electronically storing a database of a plurality of food records each 
identifying a specific food; 

responsive to selection by one or more of said users from one of said 
groups of one or more of said food records, adding one or more order records 
25 corresponding to that selection to a group order record corresponding to that 
group, and 

transmitting said group order record. 



WO 01/65460 



40 



PCT/GB01/00882 



15. A method as claimed in claim 14, wherein the group order record is 
transmitted to one or more of the users from the respective group. 

16. A method as claimed in claim 14 or claim 15, wherein the group order 
5 record is transmitted to a party other than the users of the respective group. 

17. A method of selectively providing dietary data to any of a plurality of 
users, including: 

storing electronic records representing groups of said users, at least 
1 0 some of said groups comprising more than one of said users; 

electronically storing a database of diet-related information; 

in response to an access request from any one of said users, selecting 
information from said database and transmitting said information to the 
respective user; 
1 5 recording the time of said access request; and 

in response to the current time exceeding by a threshold time the most 
recent said access request from one of said users in one of said groups, 

transmitting a message to one or more other said users in said one 
group a message identifying said one user. 

20 

18. A method of providing dietary information to a user, including : 
receiving, from the user, constant physical data representing 

substantially constant physical characteristics of a human body; 
25 a) receiving, from the user, variable physical data representing variable 

physical characteristics of said human body; and 

b) generating graphical data arranged to represent graphically said 
human body having the physical characteristics represented by the constant 
and variable physical data; and 
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c) transmitting said graphical data to the user to enable said human 
body to be graphically represented to the user; 

wherein the above steps a) to c) are repeated at intervals, such that at 
least some of the variable physical data varies between repetitions. 

5 

19. A method of providing dietary information to a user, including: 
receiving, from the user, constant physical data representing 

substantially constant physical characteristics of a human body, variable 

physical data representing variable physical characteristics of said human 
10 body and target physical data representing target physical characteristics of 

said human body; 

generating a first set of graphical data arranged to represent 

graphically a human body having the physical characteristics represented by 

the constant and variable physical data; 
15 generating a second set of graphical data arranged to represent 

graphically a human body having the physical characteristics represented by 

the constant and target physical data; and 

transmitting said first and second sets of graphical data to the user to 

enable said human bodies to be graphically represented to the user. 

20 

20. A method of managing dietary information for a user, including: 
receiving from the user target physical data representing one or more 

target values of physical characteristics of said user; 

receiving from the user, at intervals, variable physical data 
25 representing one or more variable measured values corresponding to said 
physical characteristics of said user, wherein said variable measured values 
are initially not equal to said target values, and, 

if subsequently said one or more variable measured values are equal to 
said target values, crediting an account held by said user. 
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21 . A method of providing product, service or activity recommendations 
to any of a plurality of users, including: 

storing electronic group records representing groups of said users, at 
5 least some of said groups comprising more than one of said users; 

storing electronic option records representing different products, 
services and/or activities; 

storing electronic group preference records representing the respective 
preferences of said groups of said users in respect of said different products, 
10 services and/or activities; 

selecting one or more of said option records for a designated one of 
said users on the basis of one or more of said group preference records 
corresponding to one or more groups including said designated user, and 

transmitting data derived from the selected option records to the 
15 designated user. 

22. A method of providing product, service or activity recommendations 
to any of a plurality of users, including: 

storing electronic group records representing groups of said users, at 
20 least some of said groups comprising more than one of said users; 

storing electronic option records representing different products, 
services and/or activities; 

storing electronic individual preference records representing the 
respective preferences of individual said users in respect of said different 
25 products, services and/or activities; 

selecting one or more of said option records for transmission to a 
designated one of said users; 

transmitting data derived from the selected one or more option records 
to the designated user; 
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receiving an indication from the designated user of one or more of the 
selected one or more option records; and 

modifying one or more individual preference records relating to others 
of said users in the same group or groups as the designated user, according to 
5 the indication from the designated user. 

23. A method as claimed in claim 22, wherein the option records are 
selected on the basis of one or more of said individual preference records 
corresponding to the designated user. 

10 

24. A method of electronically ordering products and/or services, 
including: 

transmitting a selection indication indicating selected one or more 
products and/or services; 
15 receiving offer information relating to the selected one or more 

products or services; 

recording the offer information on a physical medium in an 
electronically readable form; 

presenting the physical medium at a supply location of the selected 
20 one or more products and/or services; and, in response to electronic scanning 
and verification of the offer information on the physical medium, receiving 
the selected one or more products and/or services according to conditions 
indicated by the offer information. 

25 25. A method as claimed in claim 24, wherein the selection indication is 
transmitted to a merchant together with a price indication indicating a price 
offered for the indicated goods and/or services, wherein said offer 
information indicates acceptance of said price. 
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26. A method of electronically processing orders for products and/or 
services, including: 

electronically scanning, at a supply location, offer information from a 
physical medium, the offer information indicating a previous selection of one 
5 or more products and/or services and conditions applicable to the supply 
thereof; 

electronically verifying the offer information against stored 
information relating to the previous selection, and, in response to a positive 
verification, supplying the selected one or more products and/or services 
10 according to conditions indicated by the offer information. 

27. A method as claimed in any one of claims 24 to 26, wherein the offer 
information is scanned from a bar code. 

15 28. A method as claimed in any one of claims 24 to 26, wherein the offer 
information is scanned from a card. 

29. A method of electronically ordering products and/or services, 
including: 

20 transmitting a selection indication indicating selected one or more 

products and/or services, and one or more procurement options; 

receiving offer information relating to the selected one or more 
products and/or services and options; 

presenting the offer information at a supply location of the selected 
25 one or more products and/or services; and, in response to electronic 
verification of the offer information, including verification of the procurement 
options being satisfied, receiving the selected one or more products and/or 
services according to conditions indicated by the offer information. 
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30. A method of electronically processing orders for products and/or 
services, including: 

receiving, at a supply location, offer information indicating a previous 
selection of one or more products and/or services and procurement conditions 
5 applicable to the supply thereof: 

electronically verifying the procurement conditions against the actual 
conditions of receipt of the offer information, and, in response to a positive 
verification, supplying the selected one or more products and/or services 
according to conditions indicated by the offer information. 

10 

31. A method as claimed in claim 30, wherein the procurement options 
include a selected time and/or day of collection, and the electronic verification 
includes verification that the current time and/or day matches the procurement 
conditions. 

15 

32. A method as claimed in any one of claims 24, 25 and 29, wherein the 
receiving and transmitting steps are performed via an intermediate node, the 
offer information including information identifying the intermediate node. 

20 33 . A method as claimed in any one of claims 1 to 23, wherein the method 
is performed at a node of a network to which the or each said user is directly 
or indirectly connected or connectable. 

34. A method as claimed in any one of claims 24, 25 and 29, wherein the 
25 method is performed at a terminal connected to a network. 



35. A method as claimed in claim 33 or claim 34, wherein the network is a 
packet-switched public network. 
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36. A method as claimed in claim 33 or claim 34, wherein the network is a 
circuit-switched public network. 

37. A method substantially as herein described with reference to Figures 3 
5 to 5 of the accompanying drawings. 

38. Apparatus arranged to perform the method as claimed in any 
preceding claim. 

10 39. A computer program arranged to perform the method as claimed in 
any one of claims 1 to 37 when executed by a suitably arranged computer. 
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Fig. 4 
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